Salut,

Je pense qu'il est temps de penser  nous mettre d'accord au sujet de la
gestion des informations de dbogage. Voil ma vision des choses, je serais
content d'avoir ton avis: suggestions, amliorations, suppression de
features que tu retiens non implmentables, ...

Pour commencer, je vais commencer par dfinir ce que j'entends par
"informations de dbogage". Je vois 3 grands types d'informations:
1. informations symboliques niveau assembleur. Cela comprend les noms des
labels (labels de code, variables). Ces informations sont probablement les
plus simples  grer, il suffit  mon avis en grande partie de rutiliser du
code qui existe dj pour les ROM_CALLs. Ce sont aussi les seules
informations qu'on peut obtenir de l'assembleur A68k. (L'assembleur GNU gre
aussi le 2.)
2. lignes des sources. Ces informations mettent en relation les instructions
du code machine avec les lignes des sources C ou assembleur (GNU). Cela
implique rajouter un "source view" au dbogueur et de permettre de faire du
single-stepping et des breakpoints dans la fentre de source.
3. position (pour les variables "automatiques") et type des variables C. Au
niveau interface, a se traduit en l'affichage des valeurs des variables,
les watchpoints (version haut niveau des data breakpoints), ... C'est le
plus dur  grer, mais quand le 1. et le 2. seront rgls, je pense qu'il
sera invitable de nous plonger l-dessus pour que le dbogueur soit
complet.

Je compte raliser a de la manire suivante: ld-tigcc met, en plus des
excutables, un fichier nomprog.dbg qui contiendra les informations de
dbogage. Il serait bien que ce fichier soit chargeable comme un fichier TI
dans TiEmu. Le chargement se passerait idalement de la manire suivante:
* L'utilisateur "envoie" nomprog.dbg.
* TiEmu va chercher l'excutable de mme nom et pour la bonne calculatrice.
(Cet excutable pourra tre suppos non compress.)
* TiEmu l'envoie (en RAM, pas en archive, pour pouvoir mettre un
breakpoint).
* TiEmu place un "program entry breakpoint" sur ce programme. (Oui, il
faudra d'abord implmenter a, cf. mes mails prcdents.)
* TiEmu l'excute  travers la ligne de commande. Attention, ici, il faudra
un hack: il faudra faire en sorte que l'appel en ligne 1010 correspondant 
"ASAP or Exec string too long" soit trat comme un nop jusqu' ce que le
breakpoint soit atteint. Cela ne devrait pas tre trop dur  implmenter
directement au niveau de l'mulation d'instructions  mon avis.
* Ds que le breakpoint est atteint, TiEmu fait en sorte que la protection
anti-excution soit dsactive pour tous les 64 KO du programmes (pas
seulement les premiers 8 ou 24 KO).
* TiEmu charge les informations de dbogage (en les relogeant  la bonne
adresse) et affiche le dbogueur.

Mon ide du format de dbogage est le suivant: Le fichier .dbg sera en fait
un .a qui contiendra:
* symbinfo.dat: informations symboliques
* srclines.dat: lignes des sources
* cvars.dat: position et type des variables
* toutes les sources rfrences dans srclines.dat, de faon  permettre la
compilation dans un rpertoire temporaire effectue par l'IDE, ou de
dboguer facilement sur une machine qui n'est pas la machine de
dveloppement. (Les librairies statiques compiles avec informations de
dbogage devront aussi contenir ces sources, pour les mmes raisons.)
(Ceci est sujet  des changements. Tes suggestions sont les bienvenues. Les
dtails des contenus des *.dat restent  dfinir.)

Il faudra aussi qu'on se mette d'accord pour la rpartition des tches:
j'aurai certainement besoin de ton aide pour ce qui est interface graphique
(je n'ai encore rien programm en GTK), et je vais certainement m'occuper
entirement du linker. Le reste est sujet de discussion.

C'est tout pour l'instant, j'ai certainement d'autres choses encore  dire 
ce sujet, mais je n'ai pas le temps maintenant...